home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1993
/
Internet Info CD-ROM (Walnut Creek) (1993).iso
/
inet
/
internet-drafts
/
draft-ietf-dns-idpr-01.txt
< prev
next >
Wrap
Text File
|
1993-09-20
|
7KB
|
224 lines
Network Working Group R. Austein
INTERNET-DRAFT Epilogue Technology Corporation
September 1993
DNS Support for IDPR
[draft-ietf-dns-idpr-01.txt]
Status of this Memo
This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a "working
draft" or "work in progress." Please check the 1id-abstracts.txt
listing contained in the internet-drafts Shadow Directories on
nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, or
munnari.oz.au to learn the current status of any Internet Draft.
This is a working document only, it should neither be cited nor
quoted in any formal document.
This document will expire before 25 March 1994.
Distribution of this document is unlimited.
Please send comments to the author.
1. Introduction
This note documents the support needed from the Domain Name System
(DNS) by Inter-Domain Policy Routing (IDPR). The DNS changes are
minor and can be deployed with minimal impact on the installed DNS
community.
When an IDPR Policy Gateway receives an IP packet, it needs to map
the packet's IP address to an IDPR Administrative Domain (AD) in
order to deliver the packet. The initial prototype implementation of
IDPR used a configuration file to provide this mapping, but this is
clearly unacceptable for a full-scale deployment of IDPR. As an
existing, well understood, (relatively) low-overhead distributed
database, the DNS is the obvious mechanism by which to distribute
Austein Expires 25 March 1994 [Page 1]
INTERNET-DRAFT DNS Support for IDPR September 1993
these mappings.
Due to an unfortunate collision in use of the term "domain" by both
IDPR and the DNS, this note avoids unqualified use of the term
"domain."
2. The AD RR type.
We define one new DNS RR type, with symbolic name "AD" and numeric
value xxx. This RR type is class-independent; the rest of this note
discusses IN class AD RRs, with the understanding that the mechanism
described here is not tied to IP addresses. The RDATA portion of an
AD RR consists of two 32-bit integers, each representing an IDPR AD.
The two fields are the "home" AD associated with the address, and the
proxy AD associated with the address. An AD which is acting as its
own proxy (the normal case) has the same value for these two fields.
Class IN AD RRs appear in the IN-ADDR.ARPA portion of the DNS name
space. These RRs are used to map from an IP address to an IDPR AD.
We expect that it will be possible to make heavy use of "wildcard"
DNS names here, since we expect that all the hosts on a given IP
network (or subnetwork) are likely to belong to a single IDPR AD.
For purposes of discussion, assume that Miskatonic University is in
Administrative Domain 42, while Engulf & Devour, Inc., is in
Administrative Domains 666 and 17; Engulf & Devour recently purchased
Liver Donors Ltd., in order to use their Policy Gateway as a proxy
for Engulf & Devour's corporate network. The following RRs might
appear in the DNS:
Loki.Miskatonic.EDU. IN A 1.1.1.5
Thor.Miskatonic.EDU. IN A 1.1.1.6
Liver-Donors.EaD.COM. IN A 2.2.2.7
HQ.EaD.COM. IN A 3.3.3.8
5.1.1.1.IN-ADDR.ARPA. IN PTR Loki.Miskatonic.EDU.
5.1.1.1.IN-ADDR.ARPA. IN AD 42 42
6.1.1.1.IN-ADDR.ARPA. IN PTR Thor.Miskatonic.EDU.
6.1.1.1.IN-ADDR.ARPA. IN AD 42 42
7.2.2.2.IN-ADDR.ARPA. IN PTR Liver-Donors.EaD.COM.
7.2.2.2.IN-ADDR.ARPA. IN AD 666 666
8.3.3.3.IN-ADDR.ARPA. IN PTR HQ.EaD.COM.
8.3.3.3.IN-ADDR.ARPA. IN AD 17 666
In this case the AD RRs for Miskatonic University could usefully be
collapsed into a wildcard RR:
*.1.1.1.IN-ADDR.ARPA. IN AD 42 42
Austein Expires 25 March 1994 [Page 2]
INTERNET-DRAFT DNS Support for IDPR September 1993
3. Use of the AD RR type.
In the initial deployment of of IDPR, we believe that only IDPR
Policy Gateways will need to know about IDPR ADs. Thus, only Policy
Gateways will need to obtain and use AD RRs. In the long run it may
be beneficial for hosts to obtain this data as well, but it is not
necessary that they do so in order for IDPR to work correctly.
4. Bootstrapping the Policy Gateways
Since a Policy Gateway needs an AD before it can forward a packet,
the AD associated with the IP addresses of each of the Policy
Gateway's default DNS name servers needs to be part of the Policy
Gateway's configuration. Ie, there is a bootstrapping problem here,
because we can't use the DNS to obtain the ADs we need in order to
talk to the DNS. Note that the Policy Gateway's default DNS name
servers are not necessarily the root DNS name servers; indeed, clever
use of centralized DNS caches by a community of Policy Gateways will
help decrease the load IDPR will add to the existing DNS system.
Ultimately, however, this question reduces to the question of how the
Policy Gateways reach the DNS root servers.
5. Glue RRs
Since in some cases the authoritative nameservers for a particular AD
RR may be within the AD itself, it may be necessary to insert "glue"
AD RRs into some zones in the IN-ADDR.ARPA tree. These fill the same
role as the glue A RRs already in use to solve the analogous problem
with finding the IP address of a name server.
6. Security Considerations
Security considerations ane not discussed in this memo.
7. Acknowledgments
Most of the ideas in this document were derived from email
conversations with Martha Steenstrup and Robert Woodburn, without
whose help the author would still be completely clueless about IDPR
and its requirements.
8. References
[1] Steenstrup, M., "An Architecture for Inter-Domain Policy
Routing", RFC 1478, June 1993.
[2] Mockapetris, P., "Domain names - concepts and facilities", RFC
1034, November 1987.
Austein Expires 25 March 1994 [Page 3]
INTERNET-DRAFT DNS Support for IDPR September 1993
[3] Mockapetris, P., "Domain names - implementation and
specification", RFC 1035, November 1987.
[4] Lottor, M., "Domain administrators operations guide", RFC 1033,
November 1987.
9. Author's address:
Rob Austein
Epilogue Technology Corporation
268 Main Street, Suite 283
North Reading, MA 01864
USA
Phone: +1-617-942-0915
EMail: sra@epilogue.com
Austein Expires 25 March 1994 [Page 4]